I'm not against this, but just as an FYI it will need to wait for the next breaking release

Taking another look at this I'm confused, transport is required both for clients and servers. Axum in particular is a dependency of the server implementation?

Yes, in tonic, the transport feature is required for the "batteries included" server. But arrow-rs does not currently expose a high-level server API that depends on the tonic Server. Users need to choose their http2 server, for which they could use the tonic transport::server, or not.

My understanding of the tonic traits was that they were so low level that whilst in theory one could plugin an alternative this wasn't really practical. I'm still confused why this feature flag is called client when AFAICT it is required for servers and clients?

The reason behind my hesitation is feature flags are a pain to maintain and test, so we only want to add them where there is real pain

For arrow-flight it is truly only required for the high-level client, not for the server since FlightServiceServer is just a Service trait implementation. But I'm happy to rename the feature gate.

My use-case would be to build a simple server by using hyper directly, without axum or the tonic server. I wanted to use hyper 1.0 without waiting for tonic to upgrade, but turns out this isn't possible due to conflicting http crate versions between hyper 1.0 and tonic.

That is to say, I have not been able to get my use case for this PR actually working. And once tonic upgrades to hyper 1.0 and http 1.0, I suppose the only unneeded dependency would be axum itself, and I wouldn't classify that as a 'real pain'. So I think it's fair if you'd rather not do this at this point.

Heh, I figured something like that might be the case having gone down much the same rabbit hole myself, hence my question.

Given that I suggest we keep this as a draft and revisit if tonic continues to not upgrade http.

The latest tonic release has finally updated to http 1.0, so closing this